home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 498 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.7 KB

  1. Date: Tue, 14 Sep 93 14:19:57 MDT
  2. From: shenson@nyx.cs.du.edu (Stephen Henson)
  3. Message-Id: <9309142019.AA29589@nyx.cs.du.edu>
  4. X-Disclaimer: Nyx is a public access Unix system run by the University
  5.     of Denver.  The University has neither control over nor
  6.     responsibility for the opinions or correct identity of users.
  7. To: mint@terminator.rs.itd.umich.edu
  8. Subject: pl7 AHDI and ICD fun ...
  9.  
  10. Hmmm pl7 may well not have the mount() stuff. However I've been using some
  11. rather unusual methods which suggest I might have a solution to the ICD
  12. bug (which is still ICD's fault not mine!) so the caches can be left on
  13. when using huge partitions.
  14.         The protection problem with AHDI seems rather serious. If anyone
  15. has any suggestions (since none of mine seem to work) I'd love to hear
  16. them. One possibility I'm toying with is to have a pseudo boot sector
  17. which makes the sector size 512 bytes (where protection isn't a problem)
  18. and to save the real boot sector data info elsewhere (behind the super block
  19. or in the pseudo FAT's), minit would then restore this on request. The driver
  20. could then try to read the last block at startup and if it failed (or logical 
  21. lrecno bug was present) switch to physical mode.
  22.         Of course I could always grasp the nettle and read the partition info
  23. manually and interpret that and protect using a different partition id. This
  24. only then leaves the problem of drive changes and drives with no TOS partitions
  25. (e.g. how do I find out they exist?).
  26.         Of course all of these problems are AHDI specific ... It seems like
  27. AHDI may inherit ICD's crown as the number one 'pain in the arse driver
  28. software', XHDI compliant software is currently in last place on this list
  29. :-)
  30. Steve.
  31.